The rapid evolution of computer and communication technologies coupled with the robust economies of the 1980s and 1990s resulted in unprecedented growth in the information technology (“IT”) field. During this period, the need to establish a competitive advantage drove companies to faster and faster rates of change to support new product offerings and expanded services. As a result of these market pressures and time constraints, most companies elected to support new products and services by adding additional back office systems. However, due to the lack of mature integration technologies, the new systems were connected to the existing IT systems by making direct connections to the software routines already in use. The vulnerability of this design is that a change in one system produces a “ripple effect” change in every system it connects with. Over time, this incremental stacking of software systems can result in an integration ceiling. That is, at a certain point, more effort is spent on the connections than on new functionality and further expansion becomes cost prohibitive.
In the late 1990s, new integration technologies emerged that made it possible to “loosely couple” applications so that systems are no longer directly connected. Thus, changes in one system would not cause a ripple effect in any other systems. The most notable of these technologies are Message Oriented Middleware (“MOM”), Publish and Subscribe messaging, and Object Request Brokers (“ORBs”). These technologies enabled companies to re-architect their conglomeration of systems into an architecture that allows them to expand in a cost-effective manner. Technologies such as these that address the problem of integrating existing systems with new systems in an organized, efficient, and economically scaleable manner can be referred to collectively as enterprise application integration (“EAI”) technologies.
An integrated enterprise may have any number of applications which interact with one or more shared databases (also referred to as an integrated information store (“IIS”)) of the integrated enterprise through a data access layer (“DAL”). Among other things, interface control documents (“ICDs”) for an integrated enterprise describes all of the application-to-database operations taking place within the integrated enterprise. The ICDs for the integrated enterprise should describe all of these operations using a pre-defined set of standards. Otherwise, the various relationships between the applications and the IIS would be unclear and, when tested, the integrated enterprise would likely suffer from any number of system errors.
Traditionally, errors resulting when the ICD is written in violation of the standards governing the document could only be identified through a detailed manual examination of the ICD documents which model an enterprise. Depending on the complexity of the integrated enterprise being modeled, such a task can be both difficult and time consuming. It is, therefore, the object of this invention to provide a tool which simplifies this task of identifying such errors.